perm filename LISP.BUG[BUG,LSP]12 blob
sn#686861 filedate 1982-11-09 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00048 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00008 00002 BUG-LISP and LISP-FORUM
C00009 00003 ∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
C00010 00004 ∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
C00013 00005 ∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
C00014 00006 ∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
C00016 00007 ∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00018 00008 ∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
C00020 00009 ∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
C00023 00010 ∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00026 00011 ∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
C00027 00012 ∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
C00029 00013 ∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
C00031 00014 ∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
C00033 00015 ∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
C00034 00016 ∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
C00036 00017 ∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
C00038 00018 ∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
C00039 00019 ∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
C00040 00020 ∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
C00042 00021 ∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
C00044 00022 ∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
C00045 00023 ∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
C00048 00024 ∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
C00049 00025 ∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
C00050 00026 ∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
C00051 00027 ∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
C00053 00028 ∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
C00054 00029 ∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
C00055 00030 ∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
C00056 00031 ∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
C00058 00032 ∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
C00060 00033 ∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
C00061 00034 ∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
C00062 00035 ∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
C00064 00036 ∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
C00066 00037 ∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
C00067 00038 ∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
C00068 00039 ∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
C00069 00040 ∂17-Sep-82 1701 GSB@MIT-ML previous patch
C00071 00041 ∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
C00073 00042 ∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
C00075 00043 ∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
C00079 00044 ∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
C00092 00045 ∂31-Oct-82 1132 TONYH at MIT-AI
C00097 00046 ∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
C00100 00047 ∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
C00105 00048 ∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
C00123 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
Date: 20 August 1982 23:27-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: fixes to maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Can you tell us the best way to assemble a Maclisp on a tops-20
so that we can put in the various accumulated fixes in the version
on OZ? For example, the MT fix to suspend. Thanks.
∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Bug in setf and arraycall
To: Bug-Lisp at MIT-MC
Seems to be a problem with push and arraycall. Here's the source file:
(defvst bug-st
(a = (*array () t 10))
)
(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
(defun bug (self member index)
(push member (bug-st-ai self index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
And here's how Maclisp takes it:
Yale Haclisp 82 (in Maclisp 2088)
> (defvst bug-st
(a = (*array () t 10))
)
;Loading DEFVST 3
;Loading EXTMAC 183
;Loading ERRCK 20
;Loading VECTOR 64
;Loading DEFVSX 85
BUG-ST
>(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
BUG-ST-AI
>(defun bug (self member index)
(push member (bug-st-ai self index)))
BUG
>(setq b (cons-a-bug-st))
#{BUG-ST A #T-10-71712}
>(bug b 'a 4)
(A)
>(bug b 'a 4)
;G0017 UNBOUND VARIABLE
;BKPT UNBND-VRBL
> (baktrace)
BAKTRACE
+INTERNAL-UBV-BREAK← ARRAYCALL← PUSH← BUG←
It seems especially odd to me that things should blow up only after the
second call to bug.
-------
∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
To: Bug-Lisp at MIT-MC
Subject: (SSTATUS SYNTAX #/| ...)
Cc: Ellis at YALE, Ruttenberg at YALE
Trying to set the syntax of | doesn't work.
(SSTATUS SYNTAX #/| 2.) ;2 is syntax of %, :, etc.
2
'|
/↑T
Vertical bars in symbols read as control-T's.
∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
Date: 22 August 1982 18:59-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: BUG-LISP at MIT-MC, Ellis at YALE, Ruttenberg at YALE
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
(SSTATUS SYNTAX #/| 2.)
2
'|
/↑T
This is because (SSTATUS SYNTAX) doesn't know enough to set up the character
translation when it turns off a macro character. You can either do (SSTATUS
CHTRAN #/| #/|) immediately afterwords, or use (SETSYNTAX #/| 2. #/|) instead.
I started to fix this, but the code is too ugly to be believed.
∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 22 August 1982 19:29-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: BUG-LISP at MIT-MC
cc: Ruttenberg at YALE
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
It seems especially odd to me that things should blow up only after the
second call to bug.
A smaller case of the bug:
(defvst bug-st
(a = (*array () t 10))
)
(defun bug (self member index)
(push member (arraycall t (bug-st-a self) index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
After the first call to BUG it's definition has been changed to be:
(defun bug (self member index)
(push member (arraycall t <gensym> index)))
This is probably an artifact of PUSH being a fexpr (but thinking like a macro),
bug it also seems to depend heavily on the source of the array being a defvst
accessor. It doesn't happen if you are using defstruct instead. Perhaps those
responsible for defvst/push will step forward and fix?
∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Re: push/defvst interaction?
To: Alan at MIT-MC
Cc: Bug-Lisp at MIT-MC
In-Reply-To: Bawden's message of 22 August 1982 19:29-EDT
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
-------
∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
Date: 23 August 1982 02:45-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: ALAN at MIT-MC, BUG-LISP at MIT-MC
As a bit of honest practical advice, I would concur with ALAN in
suggesting that you use DEFSTRUCT in preference to DEFVST.
The story goes like this: DEFVST was supposed to be part of
a package of code which was "NILCOM," common to both NIL and Maclisp,
and presumably to be part of "common-lisp." As it turned out though,
the implementation of all of that "NILCOM" code was too tentative
and kludgy to be worth bringing up in actual VAX NIL, so instead
code like Defstruct (which is de-facto common-lisp)
was brought up. So you see, there can be little
incentive here (at MIT) to support/fix-bugs in code such as DEFVST.
On the other hand, it is quite easy for me to make available to
you an option to defstruct called "EXTEND" which does the same
job as "DEFVST" except that the interface is a lot cleaner,
and it actually works! (It is what RLB and I used last summer to
cross-compile NIL from the pdp-10 to the VAX). You can get it
by FTPing "GJC;SFIX FASL" from the MIT-MC machine. Source is in
"GJC;SFIX >" on MIT-MC.
To answer your question about source code: The most up-to-date
versions of things are on the LIBDOC, LSPSRC, and NILCOM directories
on MIT-MC. The *best* solution seems to be to keep a winning
Maclisp environment working on MIT-OZ, and let people FTP
stuff from there.
-gjc
∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 23 August 1982 17:03-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: BUG-LISP at MIT-MC
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
I heve never released a version of defstruct that had anything whatsoever to do
with ANY of the out-of-core (autoloading) MacLisp libraries. There is a
feature that made defstruct a front end for defvst which I have never released
to anyone, but that wouldn't do you any good anyway. Can you send me an
example of a defstruct that tries to load ANYTHING? Up-to-date defstruct FASL
can be found on LISP;STRUCT FASL.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
I'm not surprised that you can't compile it either.
∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
Date: 24 August 1982 18:40-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: distribution request
To: TY at MIT-ML
cc: BUG-LISP at MIT-ML
tar@MIT-ML (Sent by ←←←036@MIT-ML) 08/24/82 14:48:02 Re: Phone message
Steve Cadrak called.
Academic Computing Center
University of Vermont
Burlington, VT 05405
He would like to obtain the latest MACLISP. (He has version 2009)
TOPS-20 version 5.
(802) 656-3910
∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
Date: 24 Aug 1982 2050-EDT
From: Greg Skinner <EE.GDS at MIT-OZ>
Subject: Lisp problem
To: bug-lisp at MIT-OZ
Subject: LISP problem
Is this a bug or just a feature? (especially (gcd 15 5)
evaluating to 1, while the others seem to evaluate correctly).
Plus, is there any way that LISP can be set so that base 10
numbers are echoed as such? (re 8 = 10 and 10 = 10)
[PHOTO: Recording initiated Tue 24-Aug-82 8:37PM]
TOPS-20 Command processor 4(661)-2
@lisp
LISP 2129
Alloc? n
*
(gcd 15 5)
1
(gcd 30 10)
10
(gcd 8 4)
4
(gcd 60 30)
30
(gcd 50 5)
5
(quotient 50 4)
12
50
50
(quit)
@pop
[PHOTO: Recording terminated Tue 24-Aug-82 8:38PM]
-------
∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
Date: 24 August 1982 20:56 edt
From: Barry Margolin at MIT-MULTICS
Subject: Re: Lisp problem
Sender: Margolin.Multics at MIT-MULTICS
To: Greg Skinner <EE.GDS at MIT-OZ>
cc: bug-lisp at MIT-OZ
In-Reply-To: Message of 24 August 1982 20:50 edt from Greg Skinner
There were no bugs displayed in that session. By default, Maclisp is in
base 8, and 15(8) = 13(10) (where the notation xx(n) means the numeral
xx in base n), and the GCD of 5(10) and 13(10) is indeed 1. The
variables that control the base that numbers are input and output in are
"base", which is the base that numbers are output in, and "ibase", which
controls the input base. Associated with these is the variable
"*nopoint", which if set to T causes the decimal point that normally
follows decimal numbers on output to be suppressed. Note that any
fixnum that has a trailing decimal point (as in 100.) is also read in in
decimal, regardless of the setting of ibase, so to initially set the
base variables you should say:
(setq base 10.)
(setq ibase 10.)
∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
Date: 27 August 1982 15:51-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: Ellis at YALE, Ruttenberg at YALE, BUG-Lisp at MIT-MC
I believe that SETSYNTAX is what you want here; it assumes that the
choices (bits only, MACRO, SPLICING) are mutually exclusive. (sstatus
syntax ...) only hacks the syntax bits. In obscure applications this
is actually useful (the fact that it doesn't clobber the macro/chtran
entry, that is), because you can do strange and perverse things with
something like "." so that it is still decimal point but also acts
like a special-token (implemented as a reader macro). (I've done this.
It almost works.)
∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
From: GSB@MIT-ML
Date: 08/30/82 01:34:11
Subject: new format installed on MC and OZ
GSB@MIT-ML 08/30/82 01:34:11 Re: new format installed on MC and OZ
To: (BUG LISP) at MIT-ML
format 827 has been put on MC and OZ. the file types involved are
FASL, BRACK, FLOAT, NUM, and UMACS. This fixes a fencepost bugs
in ~$ and a misfeature in operator definition via define-format-op,
and maybe some other things which i have since forgotten.
∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
Date: 30 Aug 1982 16:10 PDT
From: JonL at PARC-MAXC
Subject: Re: fixes to maclisp
In-reply-to: GJC's message of 20 August 1982 23:27-EDT
To: George J. Carrette <GJC at MIT-MC>
cc: JONL at MIT-MC, BUG-LISP at MIT-MC
I've just returned from two weeks travelling (LispConference, AAAI, MIT
visit etc) and I didn't see you at MIT -- are you still there?
There used to be a .CTL file on MIT-XX, PS:<MACLISP>ASSLIS.CTL, which
you could just SUBMIT and it would doo all the rest. It would leave
an *uninitialized* result on SS:<MACLISP>BBLISP.EXE.<nnnn> and also
do an initialization phase leaving PS:<MACLISP>XLISP.EXE.<nnnn> and
PS:<MACLISP>LISP.SYMBOLS.<nnnn>. You then rename XLISP to LISP after
certifying that things are winning. The value of the uninitialized
file is that it's hard to patch the LISP.EXE file with the existing NDDT since
it involves changing file page accessibilities (read-only etc).
∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
Date: 31 August 1982 01:15-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Sender: VP at MIT-MC
Subject: FORMAT losing
To: GSB at MIT-MC
cc: BUG-LISP at MIT-MC
In Maclisp 2122, Format 827. on MIT-MC:
Ignoring the rough points in what these actually ask FORMAT to do ('cuz
there are a few conceptual bugs), these functions do not behave in ways
even remotely resembling what the LispM does with them. For example, the
LispM does not err, pdl-overflow, or complain of missing ~]'s. Simple
tests like (f nil), (f '(a)), (f '(a b)), (f '(a b c)) and likewise for g
should give you a feel for what I'm talking about. G'luck.
(defun f (x)
(lexpr-funcall #'format t "~#[nothing~;~S~;~S and ~S~
~:;~@{~<~% ~1,50:;~#[~1; and~] ~S~>~↑,~}~]" x))
(defun g (x)
(format t "~%;; ~{~<~%;; ~1,50:;~#[~1; and~] ~S~>~↑,~}.~%" x))
-kmp
∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
Date: 31 August 1982 23:57-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on OZ,
∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
Date: 1 September 1982 00:00-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on oz, an LH/| page disappears when the job is suspended and restarted.
One gets a memory protection violation...
∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
Date: 1 September 1982 02:04-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: hacking/assembly maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Thanks for the info, now, I wonder if I have *read* access to the
Maclisp directory on XX? sigh... it is a wonder anything gets done
at MIT inside LCS. Yes, I expected to be at the lisp conference,
but when the time came to leave it seemed more fun to stay at
ATARI and hack up some demo's in NIL on their brand-new 780.
I heard that some of the graphics in TRON were done in Maclisp
on a Foonly (by the way). Remember that bug note/question about
extened objects and arithmetic some months ago? I think it
was from the same guy, Craig Renolds?
Anyway, thats the state of things, I'll be at ATARI again in a little
while and I'll give you a call in Palo Alto, want to see some
3-D graphics in NIL controlled via the flavor system?
[No, I didn't implement a number-compiler for NIL yet, the crunching
stuff is written in (sigh) "C" which gets interfaced to NIL in the
obvious way.]
-gjc
∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Subject: WITH-OPEN-FILE
To: BUG-Lisp at MIT-MC
cc: RpK at MIT-OZ
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
``Bob''
∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:27-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: WITH-OPEN-FILE
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
There is a package on LIBLSP called IOTA which does what you want. I'm working
on a library of macros and functions to help people trying to hack Lisp
Machine compatibility. Among things in that library will be WITH-OPEN-FILE.
For now, though, IOTA is the thing to use. It's used heavily in lots of Maclisp
systems and works fine. Documentation is in LIBDOC;IOTA >
-kmp
∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:56-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: WITH-OPEN-FILE
To: RpK at MIT-ML
cc: BUG-LISP at MIT-MC, RpK at MIT-OZ
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
MacLisp does UNWIND-PROTECT by having an UNWIND-PROTECT special form just like
the LispMachine's. There is no built-in WITH-OPEN-FILE macro, but clearly you
can write your own using UNWIND-PROTECT, or wait until KMP writes one (he'll
think of some screws you never dreamed of I'll bet) or you can convert your
code to using IOTA.
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
I don't understand this question in the least. The objects returned by OPEN
don't except ANY messages. They are not message recieving objects. They do
have a printed representation, but that isn't accomplished by sending any
messages. You don't do I/O by sending them messages, but by calling functions
like PRINC and TYO and passing them the "file object" as an argument.
∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
Date: 1 September 1982 22:52-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: renamef failure
To: BUG-LISP at MIT-MC
the IOJRST at RENAM5+6 should be a JFCL. If the RNAMF fails then the
file has been closed but the jfn not released. The IOJRST after the
failing CLOSF will clobber the first error message (and probably not
allow the error to return because iojrst stack hacks probably aren't
additive). I have changed this in the source, someone patch it on
a 20?
∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
Date: 1 September 1982 23:36-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Glenn S. Burke <GSB at MIT-MC>
Cc: BUG-LISP at MIT-MC
Subject: renamef failure
Howdy!
It is patched on OZ.
--Chiron
∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
Date: 2 September 1982 01:19-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
I put a package on LIBLSP; (and <LIBLSP> on OZ) called LISPM. Please play
with this and tell me if it gives you any troubles. If no one reports any
bugs in a week or two, I'll announce it to INFO-MACLISP. The file defines
compatibility definitions for DEFSUBST, DOLIST, DOTIMES, MEXP, WITH-OPEN-FILE
and WITH-OPEN-STREAM. Documentation is in LIBDOC;LISPM > and in
OZ:PS:<LIBLSP>LISPM.LSP
-kmp
∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
Date: 6 September 1982 18:39-EDT
From: Devon S. McCullough <Devon at MIT-ML>
To: BUG-lisp at MIT-OZ
In lisp in Remote-File 14.0, LMFILE-Remote 18.0, MIT-Specific 10.0,
System 87.19, Experimental ZMail 46.3, microcode 164, No, devon,
on Lisp Machine One:
In the blue manual on page 158, 11.1 describing closures, it says
The form (closure var-list function), where var-list is a list of...
...
the value cells of the symbols. Then function is applied to the ARGUMENT. (This...
in the next-to last paragraph on the page. ARGUMENT should be plural, or I'm mixed up!
∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
Date: 6 September 1982 18:38-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
I forwarded DEVON's bug report to BUG-LISPM where it should have gone.
∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
Date: 6 September 1982 21:20-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
Why does (LISTEN) take about 100 miliseconds (0.1 second) to execute?
This seems to be a very long time.
∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
Date: 7 September 1982 16:07-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
i replied to REM
∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
Date: 7 September 1982 18:46-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: suspend tty code fix (tops-20 vts)
To: BUG-LISP at MIT-MC
cc: mt at MIT-OZ
According to MT, the problem is that Lisp is setting a whole
word with stmod rather than only the left half as it should;
this can be fixed by making it do RTMOD, and then HLL 2,TI.ST6
rather than the MOVE it now does, at OPNT2+twentysome.
This has been fixed in the source, and patched into the BBLISP on OZ.
We made a .EXE, but did not install it on <SUBSYS> yet (it was in use).
∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
Date: Tuesday, 7 September 1982 20:14-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Bug-Complr at MIT-MC
Subject: Complr's losing lossage, of course
Let's see what complr does with the following code:
-----
;;; -*- Lisp -*-
;;;
;;; COMPLR LOSSAGE!!!
;;;
(defconst const-1 0)
(defconst const-2 3)
(defmacro combine-somehow (a b)
`(deposit-byte ,b 28 4 ,a))
(defun fleep ()
(print (combine-somehow const-1 const-2))
(print (combine-somehow const-2 const-1))
(print (combine-somehow 0 3))
(print (combine-somehow 3 0)))
-----
When compiled, (fleep) prints the following:
3
0
3
805306368
Seems a little bogus, huh?
[I realize that no one does much MacLisp maintainence these days, but I just
needed someone to flame at...]
--Skef
∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
Date: 8 September 1982 00:55-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: load-byte/deposit-byte miscompilation
To: Wholey at CMU-20C
cc: BUG-COMPLR at MIT-MC
I have identified the problem in the source, but not tested or
installed the fixes yet (get to it tomorrow). There were a
couple things wrong. Stay tuned...
∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
From: GSB@MIT-ML
Date: 09/09/82 03:20:05
Subject: previous patch, to OPNT2
GSB@MIT-ML 09/09/82 03:20:05 Re: previous patch, to OPNT2
To: (BUG LISP) at MIT-ML
is incorrect. I'll publicize the correction when i stop being shafted
by losing hardware, and when i go over it with a Travers
∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
Date: 13 September 1982 16:18-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML
It's sort of a bug in Autokeep (or maybe in Twenex) that you can't set
the Autokeep bit for an entire cluster of files and have it apply to new
versions when written. I think what happened is that when Glenn wrote the
patch the other night to fix SUSPEND lossage, he didn't set the autokeep
bit back on. This was not so much an issue of OZ policy or anything silly
like that as just an easy slip to have happen. This is yet another good
reason why <SUBSYS>MACLISP should probably be an unchanging .EXE file
which does nothing more than reload some other file (such as <MACLISP>'s
MACLISP.EXE). I think this is what is done on EE and I think the reasons
are similar. In any case, sorry for your lost work. It was not intended
that it shouldn't be kept.
-kmp
∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
Date: Tuesday, 14 September 1982 10:52-PDT
From: Jonathan Alan Solomon <JSol at USC-ECLC>
To: David C. Plummer <DCP at MIT-MC>
Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML,
KMP at MIT-MC
Address: 3737 South Hoover Street Room PHE 204
Los Angeles, California 90089-0273
Phone: (213) 202-1793
Yes for V5, If you save a <SYSTEM>EXEC.EXE properly with this switch
set it will remain set for everyone. Individual users who want to
change it can simply unset it in their COMAND.CMD files.
In my exec there already exists a command to override the file
setting. People seem to be doing SET FILE (no) EPHEMERAL and (no)
AUTOKEEP at random and whenever they feel like it. If you INSTALL LISP
SYS:LISP.EXE AUTOKEEP NO CONFIRM you will *always* get a Kept lisp no
matter what anyone does to the file (this is in my exec under v4).
--JSol
∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
Date: 15 September 1982 01:50-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: < WNA msg
To: BUG-LISP at MIT-MC
(< 4.5 3)
;4.5 fixnum cant compare to flonum
args=4.5
(return '(4))
...still unhappy...
(return '(3.4))
...happy...
∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
Date: 17 September 1982 19:44-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (status ttysize) on 20X
To: ALAN at MIT-MC
cc: BUG-lisp at MIT-MC
Fixed in the source, STATUS 259 (hohoho). The sign bit is used for
(status terpri) on a per-file basis, and things like LINEL and this
code have to be careful to use magnitude only. I will patch this in
on OZ and XX shortly.
(sstatus terpri t [file]) sets this; it is probably being done by something
you load up.
∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
From: GSB@MIT-ML
Date: 09/17/82 19:46:34
Subject: (status ttysize) bug, 20x
GSB@MIT-ML 09/17/82 19:46:34 Re: (status ttysize) bug, 20x
To: (BUG LISP) at MIT-ML
i should have said, STTYS1+1 should use MOVM rather than MOVE.
∂17-Sep-82 1701 GSB@MIT-ML previous patch
From: GSB@MIT-ML
Date: 09/17/82 19:57:35
Subject: previous patch
GSB@MIT-ML 09/17/82 19:57:35 Re: previous patch
To: (BUG LISP) at MIT-ML
well it's patched in the bblisp on oz.
The scheme dump shares with lisp on the wrong dir so i can't replace
the <maclisp> copy, and XX is wedged in such a way that i can only
get in via telnet which seems to interpret <cr> as <lf> in nddt.
∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: More data
To: BUG-LISP at MIT-MC
cc: JPG at MIT-MC
Well, my feeling is that people shouldn't rely on the exact truth value
which comes back from a true/false predicate. Sad that it ws documented
like that.
By the way, here's some more data. There seems to be a pattern:
Arg1 Arg2 Return Value
A AB T
AB ABC T
ABC ABCD T
ABCD ABCDE T
ABCDE ABCDEF LESSP
ABCDEF ABCDEFG T
ABCDEFG ABCDEFGH T
ABCDEFGH ABCDEFGHI T
ABCDEFGHI ABCDEFGHIJ T
ABCDEFGHIJ ABCDEFGHIJK LESSP
ABCDE ABCDEFG LESSP
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
Date: 2 October 1982 15:31-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: ALPHALESSP: More data
To: BUG-LISP at MIT-MC, JPG at MIT-MC, KMP at MIT-MC
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP>
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
The fix is to patch the MOVEI D,QLESSP at ALPHAL to be MOVE D,VT.ITY
It only seems to matter whether D contains NIL or non-NIL except that the
contents of D get returned in the special case that JPG discovered.
∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
Date: 29 October 1982 18:17-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: [TONYH: forwarded] (bug-PROGRAM??????)
To: BUG-LISP at MIT-MC
Date: 29 October 1982 17:56-EDT
From: TONYH at MIT-AI
To: BUG-PROGRAM at MIT-AI
I have three little problems which defy all of the info we have here.
If anyone can offer any help or suggestions we'd be very grateful.:
(1) Macros which are compiled in one file cannot be called from
another file if the latter is also compiled. The error message is
MACRO NOT PERMITTED IN UUO CALL. We think it must be something to
do with the declarations made at the tops of files for the compiler's
sake, but we have no information about them, and all our guesses based on
MacLisp source files have failed;
(2) We have tried to make the tilde a special readmacro. The idea is that special
comments within a file (they're quoted strings) should be prefaced by the tilde,
and that when the file is loaded the readmacro will place these comments
into a HELP system. The file containing the readmacro definition is
compiled, and the idea works well as long as the files subsequently loaded
(those with the tilde-ised comments in) are not compiled. The readmacro won't
work on FASL files , including its own file.
Also, does anyone happen to know how to stop typed-in characters from
being echoed back to the terminal? I'm trying to build alittle keypad-
driven editor, but my keypad (VT52) sends three characters at once,
which I'd rather not see!
Oh - I've just remembered another one. Our MacLisp occasionally has fits
of GC←DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of
us can understand the source code which might tell us why...
Many thanks in advance to anyone who can help, from the very heart of
quaint little old England.
Tony.
∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
Date: 29 OCT 1982 1700-PDT
From: JONL at PARC-MAXC
Subject: Your recent note on MacLisp errors
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
Your questions (1) and (2) arise from misunderstanding how and
when macros are applied (both readmacros and interpreter/compiler
macros).
1) Macros are never "called" in the sense that we think of calling
a funciton -- they are "expanded" by the interpreter and compiler,
but of course if they are not available to the compiler when compiling
some file, then no expansion can be done, and the compiler will defaultly
assume that the unknown name stands for a function call (rather than for
some macro to be expanded).
2) when READing a file, the s-expressions are stored as ascii text, and
the readmacro characters are invoked when such character is encountered
by the READer; FASL files, on the contrary, store either the
compiled versions of programs, or a special internal-format for other
s-exressions. Perhaps a reasonable approach is for the tilde macro
merely to append to some global list, which is then output near the end of
your file. Thus both ascii files being READ and compile dFASL files would
have a consistent representation of what is wanted in the HELP system (namely,
the list of goodies which was produced by READing the ffile in the first place).
As for deletion of the echo, it will depend on what kind of system you are using
TOPS10 or TOPS20. If the latter, you can turn of echoing by an appropriate STATUS
call which sets the bits in the TOPS20 echocontrol words; There may be some explanation
of this (i.e., the extended STATUS calls for TOPS20) in the note which I used to
attach to the distributed MacLisp tapes.
As for the GCDAEMON reported errors, it sounds like you have a copy of the STRING
package from early to mid 1980. Many bugs in it were fixed in late 1980 and
very early 1981, so these problems should go away if you can get the current
distribution (which was supposed to have taken place just as I was leaving MIT
in mid March of this year.)
More hints on problems (1) and (2)
Thus usual procedure for using "compiled" macros is to seperate them out
into a file by themselves, and have them loaded into the compiler each time
you compile some file which might use some of them. Admittedly this is not quite
as nice as defining the macros where they might "naturally" occur, but . . .
Suppose you have your tilede macro collect some data into TILDELIST. Then at the
end of the file you could put a form
(SETQ DATASTUFF '#.TILDELIST)
this wouold be one way of insureing that DATASTUFF would have the save value after
loading the FASL file as when loading thee source file.
∂31-Oct-82 1132 TONYH at MIT-AI
Date: 31 October 1982 13:05-EDT
From: TONYH at MIT-AI
To: BUG-LISP at MIT-AI
Dear JONL -
Thank you very much for your help. Unfotunatley, in trying to make
use of it ZI seem to have made things worse, to such an extent that the system
itself pleaded with me to call you again. I'd better show you what I'm
doing - you'll probably see at a glance what horrors I'm perpetrating on your
long-suffering MacLisp:
(declare (SETQ DEFMACRO-FOR-COMPILING 'T DEFMACRO-DISPLACE-CALL 'T)
(special helplist))
;;; During loading, the tilde (~) readmacro allows the special comments
;;; in this file to be stored for later access by the APROPOS function.
;;; On the property-list of 'HELP, under the property 'COMMENTS, will
;;; be found a list of the comments, each element being a dotted pair
;;; of the unquoted part of the comment and the quoted part.
(eval-when (compile load)
(and (status feature COMPLR)
(own-symbol DEFREADMACRO /~-readmacro))) ;superstition...
(eval-when (eval load compile)
(setq helplist nil)
(defmacro defreadmacro (char &rest body)
(let ((macro-name (symbolconc char '-readmacro)))
(setsyntax char 'macro macro-name)
`(defun ,macro-name () ,.body)))
(defreadmacro /~
(let* ((/↑q t) (comment `(,(read) ,[atsign](read))))
(push comment helplist)
t)))
[atsign] intended to represent the symbol on this machine!
Then follows the comment itself:
~MSG "Simple formatter..."
...and the function it is supposed to describe - also a macro. Then,
a line I added in the belief that it was the kind of thing you were advising:
(putprop 'help '#.helplist 'comments)
That's the end of the file. I then tried to compile it:
;BKPT DATA So I did:
$p
(COMMENT **ERROR** #75526 Unrecognizable datum ←← Collecatoms in function FOO)
; %%%%%%%%%%%%%%%%%%%%COMPILER ERRO(R - CALL JONL%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
;BKPT BARF
Ugh, what have I done? Sorry to bother you with this again so soon. I would
have flogged on with it on my own except for what the machine said just there.
As to your other valuable help - yes, I had just about reached the same
conclusion regarding how to re-use "compiled" macros. I just hoped,
(we are riddled with superstition here) that there might be a clever way
around the problem. We seem to have the May '82 version of STRING, but
I'll check that the dates are right. And Lord alone knows what happened
to any notes you included with the source tapes - such things go
through many administrative hands before reaching poor hackers like us!
Thank you again, anyway.
Tony.
∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
Date: 31 October 1982 16:04-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: lossage after lossage
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
It doesn't help to be superstitious about Maclisp. In fact, it helps a lot
to keep things as simple as possible, not using a feature unless you
really understand what it is doing. Here is what I recommend:
(1) In one file, put your "compile-time" environment. This includes
macros and readmacros, and special declarations, e.g.
(herald macros)
(defvar helplist)
(defun help-comment-readmacro ()
(push (cons (read) (read)) helplist))
(setsyntax #/~ 'macro 'help-comment-readmacro)
(defmacro helplist-begin ()
(setq helplist ())
(defmacro helplist-end ()
`(defprop help ,helplist comments))
;; Note that I didn't bother with defining a fancy DEFREADMACRO, since
;; it just isn't worth the trouble.
(2) Then your source-file would look like :
(eval-when (eval compile)
(or (get 'macros 'version) (load "macrofile")))
(helplist-begin)
.... stuff stuff stuff ...
(helplist-end)
(3) Do not use the Maclisp string package. It is has proven to
be completely unreliable. An alternative, which has been used in a text
editor written in maclisp, is in "GJC;CHAR >" on MIT-MC.
Someday a reasonable string may be released as part of the Maclisp
distribution, until then you should be able to get by fine with
something like "GJC;CHAR >"
Note that this file should be loaded at COMPILE and RUNTIME,
since it includes declarations, readmacros, and code.
-gjc
∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
Date: 1 Nov 1982 0055-PST
From: David Eppstein <CSD.Kronj at SU-SCORE>
Subject: SUBFORK module (LEDIT)
To: Bug-LISP at MIT-MC
The lines in SI:GIVUP-TTYINTS that set the inferior fork's capabilities
are switched, so that the fork gets no caps, causing LEDIT to lose big.
Old code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←inferior)
(boole 2 1←18 cap←poss←inf)
1)
Correct code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←poss←inf)
(boole 2 1←18 cap←inferior)
1)
David
-------
∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
Date: 3 NOV 1982 2058-PST
From: JONL at PARC-MAXC
Subject: 4th level indirection -- maybe you haven't yet seen this?
To: info-lisp at MIT-AI, info-lispm at MIT-AI
cc: gls at MIT-AI, rpg at MIT-MC
Date: 3 Nov. 1982 1:49 pm PST (Wednesday)
From: Treichel.PA
Subject: Lisp Song
To: CIS↑
Reply-To: Treichel
Have you seen this?
Jeanie
---------------------------
Date: 3 Nov. 1982 4:23 pm EST (Wednesday)
From: Gafter.Henr
Subject: LISP song
To: AllWhimsy↑.pa, Language↑, Gottwald, KAnderson
cc: Gafter
This was in the uucp bboard net.jokes recently.
-------------------------------------------------------
From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
Another Glitch in the Call
------- ------ -- --- ----
(Sung to the tune of a recent Pink Floyd song.)
We don't need no indirection
We don't need no flow control
No data typing or declarations
Hey! Did you leave the lists alone?
Chorus:
All in all, it's just a pure-LISP function call.
We don't need no side effect-ing
We don't need no scope control
No global variables for execution
Hey! Did you leave those args alone?
(Chorus)
We don't need no allocation
We don't need no special nodes
No dark bit-flipping in the functions
Hey! Did you leave the bits alone?
(Chorus)
We don't need no compilation
We don't need no load control
No link edit for external bindings
Hey! Did you leave that source alone?
(Chorus, and repeat)
------------------------------------------------------------